Minutes from 2007-02-02: Introducing Autonomy Behaviors in the AUV's

Feb 2/2 meeting notes from [~kanna]:

1. Two separate connections
one for state
other for commands
these have subsequently been deemed to be bidirectional

2. Read the mission configuration script as it is; the structure is

ID#
	behaviour {
		keywod = value;
	....
	}

with the last token being most important

3. Tokens are placed on a linked list executed on a 200 ms control loop

4. We will need to modify the VCS (Vehicle Control System) s/w which nominally reads mission script; instead needs to get commands one at a time from the socket connection."Layered control" reads in mission file, converts to objects and sets up 200ms loop now instead of reading, it sets up a socket connection. Commands/requests to be as strings which can be handled with existing parser on the VCS side. See attached figure on VCS and AMC.

5. Adaptive Mission Controller has 3 functions
1. create behavior
2. destroy behavior
3. behavior "done"

6. When a behavior terminates, then it will need to tell the AMC of its termination. All behaviour have a timeout

• lots of constants in the behaviors; how do we bring that data over to the AMC without redundancy?
• some parameters are hard-coded; we will need to parameterize them on the MVC side
• real need of information about the achievement SUCCESS, FAILED, TIMEOUT
• at initialization the AMC will send safety behavior parameters
• important if no behavior left then abort we need to be aware about that and react accordingly -> We will need an IDLE behavior

7. Aborting a mission will be based on what the AMC sees. Do so by ensuring no tokens on are on the behavior stack.

8. Have a loop back to test the path between the MVC and AMC. Use "setpoint" (tells vehicle to run with a command heading angle or depth). Can test with a simulator.
init behavior
get state back

9. State ought to be in binary form to handle the quantity of data coming back.

10. From a timing perspective, call to a behavior can be blocked on the AMC's side since a single 'tick' inside the AMC could be longer than 200ms. Blocking on MVC will happen to a max of 200ms and will return when a behavior is spawned. If the behavior does not come back within 400ms , then there is a problem on the MVC and so abort the entire mission

11. Who does what/when; Baseline integration:
AMC - init for timer and depth envelope

• activate set point behaviour
• obtain state information with telemetry
• client adaptor implementation
• "exec" to invoke client
  MVC - set up socket connections
• stub out behavior connection
• taking the string and putting it onto the stack
• get the stack to execute (different from current, since entire mission script is run)
• run all the code on a QNX box by 7th
• telemetry process Rob M

12. To start the AMC it might be done with a script while logging in as is currently done in AUV Ops. H/w in loop test in March; attempt to do at-sea tests beginning of April.

13. We will meet every week regularly Monday morning 10am for a quick half hour in Surface Commons.

14. Rob telemetry: grab data from Layered Control and send chunks of it to AMC;
Rich H: modify layered control to take commands and modify the command stack
Hans: AMC h/w bolted on AUV by 2/15 (CTD is inhouse for next 2 weeks so Hans can integrate)